Configuration Representation and Modeling Using Configuration Spaces

ABSTRACT

Configuration spaces facilitate the useful presentation of data, particularly configuration data used for representing configured products. Products include features, and common features can be grouped by families. Configuration spaces can be achieved by consolidating selected data without losing useful information. Configuration spaces break down the “universe” of possible configurations into constituent spaces defined by groups of rules for a selected feature. Common dependencies between the selected feature and related features can be consolidated to produce a more minimal form of the data used for representing the selected features and related features. Configuration spaces can provide a useful graphical view of the breakdown of all rules written for a single feature or multiple features. The data present in this view can be analyzed to, for example, study the dependency paths of an existing configuration and better understand the impact of revising configuration relationships.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates in general to the field of informationprocessing, and more specifically to a system and method forrepresenting and modeling the configuration of products.

2. Description of the Related Art

Configurable products can be described by sets of selectable featuresthat make up the product. A feature represents an option that can beordered on a product. For convenience, selectable features are generallygrouped by families. Families are typically classified as groups offeatures with the same functional purpose. Example families for anautomobile are “version,” “trim package,” “exterior package,” “drives,”“engines,” “series,” “tires,” “markets,” “wheels,” “seats,” and“transmissions.” An example feature from the engines family is a “4.5liter V8.” Features relate to each other via configuration rules. A rulecan be characterized as generally including a ‘left hand side’, (LHS), a‘right hand side’ (RHS), and a specified relationship between the LHSand RHS. Each LHS feature may be associated with one or more RHSfeatures, which indicates that a single feature in the LHS may beconstrained or otherwise qualified by one or more RHS features. The RHSdescribes when a rule is in effect and what features are particularlyaffected. For example, a rule with a RHS of “XA, XB” means that the ruleis in effect in cases where you have at least XA and XB in a buildableconfiguration, and XA and XB are features particularly affected by therule along with the LHS feature. Configuration rules includeoptionalities that define a relationship between the LHS and RHS.Example optionalities include “S,” “O,” and “N,” which translate to“standard,” “optional,” and “not available,” respectively. A specificexample of a rule containing an optionality would be “the 4.5 liter V8engine is standard on the XL trim.” In general, a feature is related toanother feature if a rule has been written for the selected feature thatreferences another feature. For example, for the above rule, “4.5 literV8 engine” forms the LHS, “XL trim” forms the RHS, and “standard”specifies the relationship between the LHS and RHS of the rule. Thecollection of product configuration rules is generally referred to as aproduct's configuration model.

As rules are developed to define valid product configurations,dependencies arise between various families and features of families.For example, the presence of a particular wheel in a product may dependupon the particular version of the product. A chain of dependenciesoften arise. For example, the choice of a particular wheel may dependupon the “version” and the “trim package” may depend upon the“transmission,” and the “transmission” may depend on the “market,” etc.Although a product may include many features, features are not relatedif there is no dependency path that defines a relationship. For example,there may be no relationship between the choice of a wheel and thechoice of a transmission or seat.

It is often useful to select a particular feature of a configurableproduct and analyze all the other features that the selected featuredepends upon in order to be part of a valid, i.e. buildable,configuration. For example, a user, such as a configuration modeler, maywant to know what features of an automobile have a dependantrelationship with a selected feature. Table 1 sets forth all thefeatures of families that have a relationship to the Engine family on anexample automobile:

TABLE 1 Features Relating to the Family Engine Family Market USA,Mexico, Canada, Europe, South America (S.A.) Trim XA, XB, XC Engine V4,V6

If a user would like to, for example, display the relationships betweenthe V4 engine feature and features relating to the V4 engine, a gridcould be displayed as in FIG. 1 that depicts the relationships betweenthe selected V4 engine and the related families of Table 1 for theexample automobile, e.g. the V4 engine is optional with Trim XA in theUSA. The display of FIG. 1 is not particularly complicated andcumbersome.

However, as revealed in Table 2, when the number of related families andfeatures increase displaying the relationships between features becomesvery difficult when using normal sized displays, such as a 15-20 inchmonitor. Table 2 sets forth the families and the number of features (the“feature count”) therein that have a relationship to the wheel family ofthe example automobile.

TABLE 2 Feature Family Count Version 5 Trim Package 5 Exterior 5 PackageDrives 2 Engines 6 Series 3 Tires 15 Markets 40 Wheels 12

The feature count in Table 2 represents 32,400,000 configurationcombinations and resulting data cells. The explosion of the number ofdata cells stems from the fact that conventional configurationanalytical methods produce all possible combinations of the dependentfeatures. All these combinations are studied to ensure there are nooverlaps and/or missing data for possible buildable productconfigurations. Viewing configurations, as in FIG. 1, presents anexcellent way to permit a user to analyze feature relationships in aconfiguration model. However, once the number of combinations increasessufficiently to preclude normal viewing, visual analysis is precludeddue to the user confusion caused by the amount of data represented.

SUMMARY OF THE INVENTION

In one embodiment, configuration spaces facilitate the usefulpresentation of data, particularly configuration data used forrepresenting configured products. Configuration spaces can be achievedby consolidating selected data without loosing useful information. Thedegree of consolidation achieved can be significant enough to permitdisplay of data using conventional display technology.

In one embodiment of the present invention, a method of displayingconfiguration relationships of a product wherein families of productfeatures are related to each other through dependencies comprisesselecting one of the product features. The method also comprisesdisplaying representations of the product features of one or more of thefamilies that relate to the selected product feature, wherein theproduct features of a family that have common child dependencies areconsolidated into a single representation.

In another embodiment of the present invention, a method of modeling aconfiguration of a product, wherein the product includes families offeatures, the method comprising selecting a feature of the product andselecting one or more additional features of the product. The methodfurther comprises associating the additional features with the selectedfeature using one or more configuration rules and displaying arepresentation of the additional features organized in accordance withthe configuration rules, wherein the additional features are grouped byfamily and organized into dependency relationships in accordance withthe configuration rules, and additional features belonging to a commonfamily and having common child-dependency paths are consolidated intorespective feature superset representations.

In a further embodiment of the invention, a configuration space systemcomprises a model having a plurality of configuration rules, whereineach configuration rule relates a selected feature of a product to oneor more additional features of the product via an optionality, whereinthe product includes multiple families of features. The configurationspace system further comprises a processing engine to determinedependency paths among the additional features and to display arepresentation of the additional features by family, wherein the productfeatures of a family that have common child dependencies areconsolidated into a single representation.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention may be better understood, and its numerousobjects, features and advantages made apparent to those skilled in theart by referencing the accompanying drawings. The use of the samereference number throughout the several figures designates a like orsimilar element.

FIG. 1 (prior art) depicts a grid containing relationships betweenfeatures of an automobile.

FIG. 2 depicts a configuration space concisely representing therelationships depicted in FIG. 1.

FIG. 3 depicts a configuration space system.

FIG. 4 depicts a configuration space.

FIG. 5 depicts operations of an embodiment of a modeling tool thatimplements a configuration space representation and modeling process anda modeling tool interface.

FIGS. 6-10 depict an example modeling task performed by the modelingtool of FIG. 5.

FIG. 11 depicts a trie data structure.

FIG. 12 depicts a trie data structure in binary form.

FIG. 13 depicts a trie data structure with consolidated nodes.

FIG. 14 depicts a trie data structure in its minimized form withassociated binary values.

FIG. 15 depicts a trie data structure minimization process.

FIG. 16 depicts a block diagram depicting a network environment in whicha configuration space system may be practiced.

FIG. 17 depicts a computer system.

DETAILED DESCRIPTION

The term “product” is used herein to generically refer to tangibleproducts, such as systems, as well as intangible products, such asservices.

Technology referred to herein as “configuration spaces” has beendeveloped to facilitate the useful presentation and modeling of data,particularly configuration data used for representing configuredproducts. Configuration spaces can be achieved by consolidating selecteddata. The degree of consolidation achieved can be significant enough topermit display of data using conventional display technology.

Configuration spaces break down the “universe” of possibleconfigurations into constituent spaces defined by groups of rules for aselected feature. Common dependencies between the selected feature andrelated features can be consolidated to produce a more minimal form ofthe data used for representing the selected features and the relatedfeatures. Configuration spaces can provide a useful graphical view ofthe breakdown of all rules written for a single feature or multiplefeatures. The data present in this view can be analyzed to, for example,study the dependency paths of an existing configuration and betterunderstand the impact of revising configuration relationships.Configuration space representation can provide tremendous advantagesover conventional representations by, for example, reducing the numberof columns of data that a user sees as well as preserving the way theuser enters rules on grids without any “extra” qualifiers. This shouldlessen confusion or opportunities for misunderstanding of therepresented data between the user intent and the system rules. Thus,configuration spaces aid in the creation and modification ofconfiguration models.

Before describing the creation of configuration spaces, an examplegraphical display of a configuration space 200 is depicted in FIG. 2 toprovide general context for the subsequent description. An analysis ofFIG. 1 reveals that several families and features have common childdependencies. Configuration space 200 exploits this commonality byconsolidating features that have common child dependencies. FIG. 2depicts consolidated features with bracketed ellipses, i.e. “{ . . . }”.Consolidating features having common child dependencies results in amore minimal representation of the configuration relationships betweenthe families in Table 1 and the V4 engine. From a typical modeler'sperspective, such consolidation does not sacrifice information useful inanalyzing the configuration model and subsequent modifications.Furthermore in this embodiment, configuration space 200 efficientlylimits the amount of data displayed by only providing data on featuresrelated within a configuration model to the selected feature.

Referring to FIG. 3, a configuration space system 302 includes amodeling tool 310 having with read/write access to configuration model304. The configuration space system 302 can be used to visuallyinterpret configuration model 304, generate configuration model 304, andmodify configuration model 304 in accordance with user input 306.Configuration space system 302 displays a configuration space and usertools using display 308, which may be a monitor, projector, or otherdisplay device.

Modeling tool 310 allows a user to revise, create and otherwise generateconfiguration model 304. Modeling tool 310 can use data entered directlyby a user or selected by a user from a database 312. A more detaileddescription of modeling tool 310 is presented below. Configuration spacesystem 302 may be implemented, for example, using software and hardwareto execute the software and access the stored data of model 304.

FIG. 4 depicts configuration space 400 which displays the relationshipbetween selected feature FE and features of the related families. Table3 contains the rules that define the relationships. In Table 3, featuresare designated by 2 letter combinations with the first letter in thecombination being the family designation, i.e., feature “XY” is from thefamily “X”. For example, suppose configuration model 400, an embodimentof configuration model 304, includes 20 families, A through T, in aproduct. Suppose further that a user selects feature E from family F(referred to as “FE”) and desires to see the universe of features thatFE relates to in a valid configuration. As shown in Table 3, theselected feature FE is related to families A through E because familiesA through E all have features on the RHS of rules that have FE on theLHS. Table 4 contains a key to the symbols used in Table 3.

TABLE 3 Rule Representation for Selected Feature “FE” Selected FeatureOption- (LHS) ality Related Features (RHS) 1. FE — AA ~{BA}   2. FE S ABBA 3. FE — ~{AA, AB} 4. FE S AB BZ CD DF 5. FE — AB ~{BA, BZ} 6. FE — ABBZ ~{CD}   7. FE — AB BZ CD ~{DF}   8. FE N AA BA CE DC EF 9. FE O AA BA~{CE}   10. FE O AA BA CE DC ~{EF}   11. FE N AA BA CE DH EF 12. FE O AABA CE DH ~{EF}   13. FE N AA BA CE DJ EF 14. FE O AA BA CE ~{DC, DH, DJ}15. FE O AA BA CE DJ ~{EF}  

TABLE 4 KEY to TABLE 3 Optionality S Standard — No rule N Restricted OOptional Feature ~{“contents”} A feature set that includes every featurein a family except the “contents” This consolidated feature set may alsobe referred to as a “polar set”.

From Table 3 it can be seen that family A occurs most frequentlyfollowed by B, C, D, and E, in that order. In general, the display ofconfiguration space 400 can be minimized by placing families occurringmore frequently on the RHS of rules at a higher level since Family Aoccurs most frequently, Family A is positioned at the highest level. Ina tree depiction, Family A would be at the root node and theoptionalities would be at the leaf node. Note that the rules in Table 3include consolidated features represented by negative sets, i.e. the setof all features ‘not’ contained in the brackets. Consolidated featuresmay be represented in other ways, such as positive sets.

The rules in Table 3 are arranged for convenience to easily show thedependency paths in configuration space 400. Each row in Table 3illustrates a complete dependency path with the selected feature FEbeing the leaf (i.e. at the end or lowest level) of all dependencypaths. As described above, features in a family with common childdependency paths may be consolidated to minimize representation.Configuration space 400 represents maximum consolidation because all thedependency paths are unique. It will be clear to those of ordinary skillin the art that configuration space 400 could be displayed in any numberof ways. For example, the cells depicted in configuration space 400could be replaced by nodes in a hierarchical graph or tree.

FIG. 5 depicts the operations of an embodiment of modeling tool 310 thatimplements configuration space representation and modeling process 500and modeling tool interface 600 (FIG. 6). Process 500 will beillustrated with an example modeling task described below in conjunctionwith FIGS. 6-10. In the example, the product is an automobile and theselected feature is an engine referenced by the symbol BAAAA. Theexample will illustrate the creation of an embodiment of configurationspace centered upon the selection of an engine and the features andfamilies that the selected engine depends upon to be part of a validconfiguration of the automobile. This example assumes that configurationmodel 304 initially contains no rules.

As discussed above, in one embodiment configuration spaces provide a wayof displaying product features that are related to a selected featurevia the RHS and LHS of rules, respectively. Operation 502 is used toinitially select the LHS ‘selected feature’, to add qualifying features(RHS), to modify qualifying features, and to select optionalities torelate the selected feature and qualifying features. In operation 502, auser selects a feature or deselects a previously selected feature. Inone embodiment, the optionalities associated with each dependency pathwill be at the lowest level of a dependency path for a productconfiguration. Referring to FIG. 6, modeling tool interface 600 includesa find feature window 602 that is populated with data from database 312.Features in the find feature window 602 can be selected as “qualifiers”or “qualifying features” of the selected feature. A feature is aqualifier when it is in the dependency chain of the selected feature,e.g. is on the RHS of a configuration rule with the selected featurebeing on the LHS.

Referring to FIG. 5 and FIG. 6, to initiate modeling and generation of aconfiguration space based on a particular selected feature a userinitially selects the LHS feature. In the embodiment of configurationspace 608, the user selects BAAAA, a 5.0 L V8 engine, from find featurewindow 602 as the selected feature. BAAAA is then displayed as theFeature Code in feature window 604. In one embodiment of process 500,the initial default is BAAAA on the LHS with ALL being standard, whichequates to adding Rule 1 to an embodiment of configuration model 304.Thus, modeling tool 310 is used, in one embodiment, to create rulesembodied in configuration model 304.

-   BAAAA S ALL Rule 1.

“ALL” on the RHS equates to the absence of any qualifiers (i.e. the RHSis empty in Rule 1), and a RHS of ALL means that Rule 1 is in effect inall cases . . . . In other words, there is no defined dependency betweenBAAAA and any one family, and, thus, you have at least “nothing” in abuildable configuration. The appearance of “ALL” on the RHS of a rulerepresents an empty set of qualifiers. In one embodiment, the use of“ALL” is “S” no matter what else is in the product. Although this mayinitially seem counter-intuitive, by looking at the configuration space608 the ALL space is the initial universe of RHS features, whichcontains “nothing,” and the universe is subsequently populated byadditional rules. Configuration space 608 represents one embodiment ofconfiguration model 304. Configuration space 608 is depicted as a table.It will be understood by those of ordinary skill in the art that thereare a myriad of ways to display configuration space 608 withoutdeparting from the teachings herein. For example, rather than display asa table, configuration space 608 could be displayed in a circular graphwith levels emanating from the center or from the perimeter. Theconfiguration space 608 could also, for example, be displayed as atraditional tree with consolidated nodes.

To begin generation of configuration space 608, operation 504 queriesfor all rules with BAAAA on the left hand side. In this example, Rule 1is the only existing rule in configuration model 304 with BAAAA on theleft hand side. Operation 506 generates the related family list. Nofamilies are related to BAAAA as evidenced by “All” (an empty set) beingpresent on the RHS of Rule 1.

Operations 506-512 focus primarily on generating information that makesrendering of configuration space 608 possible. Since only one ruleexists at this point, Rule 1, generation of configuration space 608 isrelatively straightforward. However, the discussion below will alsoapply to more complicated instances involving multiple rules. Inoperation 508, family ordering is computed, which is one optionaltechnique for minimizing the data representation of configuration space608. The technique reviews the frequency that a feature occurs on theRHS in all rules in the configuration model 304 represented byconfiguration space 608. The more often a feature occurs on the RHS, thefeature's family will appear closer to the root node in the dependencypath depicted by the configuration space. In configuration space 608, afamily occurring higher in the dependency path would be represented by ahigher row.

Operation 510 ensures that all rules will be added to the configurationspace 608. Adding rules to the configuration space 608 involvessplitting the configuration space 608 when a new rule is added thatincludes on the RHS a feature of a family already present in theconfiguration space 608. When a rule is added that includes a feature ofa family that is not already present in the configuration space 608operation 510 adds a layer to configuration space 608. Operation 510 canalso remove rules that are selected by a user for deletion. Theconfiguration space 608 is then appropriately reconfigured to displayaccurate dependency paths.

It may be desirable to further optimize the display of configurationspace 608 by minimizing the data representation of configuration space608. If further minimization is desired, process 500 also includesoperation 512. In one embodiment, operation 512 a trie data structure(also referred to as a “trie”) is generated. The description of the triedata structure and associated minimization operations are presentedbelow in conjunction with FIGS. 11-15.

In one embodiment, process 500 performs family ordering and minimizationoperations 508 and 512, respectively, on an ‘as requested’ basis ratherthan during each pass through process 500. For example, in oneembodiment, by selecting the ‘Columns’ tab in FIG. 6, a user canmanually rearrange family ordering. In another embodiment, a user canrequest process 500 to perform operations 508 and/or 512.

Operations 514-518 assume that the configuration space 608 will bedisplayed by a software application that interprets and rendershypertext mark-up language (HTML), such as a web browser. It will beunderstood by those of ordinary skill in the art that any other dataformat compatible with the configuration space system 302 and display308 can be used to display configuration space 608. In operation 514,tags and display criteria are used to format the data acquired throughoperation 512 into an extensible mark-up language (XML) document. Note,as rules and families are added, the dependency paths depicted byconfiguration space 608 will split and grow, respectively. Thus, it ispreferable to track each node and cell in the dependency path to assistin accurately portraying the configuration space 608 using XML. One wayto render the trie into XML is to use a breadth-first order traversal ofthe trie and render each node as it is visited. The resulting XML isthen well suited for display in a table-like structure. The XML documentand a corresponding XML stylesheet (XSL) are transmitted to an Internetbrowser application, such as Internet Explorer 5.0 or greater orNetscape 6.0 or greater. In operation 518, in a well-known manner, thebrowser utilizes the XSL to transform the XML document into an HTMLdocument that will display the configuration space 608. In operation520, configuration space 608 can be viewed, for example by displaying ona computer system monitor. Operation 522 waits for the next userselection before returning process 500 to operation 502.

Modeling continues through the creation of new rules or the modificationof existing rules. Referring to FIG. 7, two families are sequentiallyintroduced into the configuration model 304. In one embodiment, for eachproduct the number of features in a family is predetermined by the userand can be any amount. Family “TRM” is a family of trims, such asLimited and Standard. Family “WHL” is a family of wheels having apredetermined number of wheels.

In the find feature window 602, the family WHL is displayed by modelingtool interface 600 along with a subset of available features, WHLAA andWHLAB. In operation 502, the user selects WHLAA and then selects TRMAC,which can be located by scrolling through find feature window 602. Anoptionality is selected by scrolling through optionality window 606.Example optionalities are shown in Table 4. “M,” mandatory, is shown asselected. The modeling tool 310 then creates a rule with the selectedfeature on the LHS, the selected qualifiers on the RHS, and anoptionality to relate the RHS and LHS. Thus, by selecting WHLAA andTRMAC and optionality “M,” Rule 2 is created and added to an embodimentof configuration model 304. By selecting “New Rule” tab, modeling tool310 would display the new rule as Rule 2, shown below:

-   BAAAA M TRMAC, WHLAA Rule 2.

In one embodiment, configuration space system 302 also includestechnology to determine conflicts in rules, in configuration model 304when a new rule is added. As a side effect to avoid overlapping rules,Rule 1 is deleted and replaced by Rules 3 and 4 are added. Rule 3indicates that feature BAAAA is standard with the set of all trimpackages in the TRM family except for TRMAC. Rule 4 indicates that BAAAAis standard with TRMAC when combined with any WHL family feature exceptWHLAA.

In the embodiment of configuration space 608, the ALL row is not shownto conserve space, but nevertheless the configuration space 608, in oneembodiment, represents all rules involving BAAAA (or any selected LHSfeature).

Thus, the current set of rules in configuration model 304 includes Rules2-4.

-   BAAAA M TRMAC, WHLAA Rule 2.-   BAAAA S ˜{TRMAC} Rule 3.-   BAAAA S TRMAC, ˜{WHLAA} Rule 4.

Operation 504 queries for all rules with BAAAA on the LHS. Rules 2-4meet the query criteria. In operation 506, the related family listconsists of families TRM and WHL. In operation 508, the TRM familyoccurs most frequently, so TRM is placed at the root level, a higherlevel than the WHL family. Operation 510 adds Rules 2-4 to configurationspace 608 and deletes Rule 1. Operation 512 examines a trie datastructure that represents Rules 2-4 and minimizes the configurationspace 608 by combining parent nodes having common sub-trees. Operations514-518 render the configuration space 608 into a viewable HTML documentin the manner described above so that the configuration space 608 can beviewed in operation 520.

Referring to FIG. 8, a full grid 802 can be displayed to show allcombinations of families in the example configuration. Note that grid802 occupies substantially more screen area than a comparably sizedconfiguration space 608, yet configuration space 608 displays theequivalent information.

Referring to FIG. 9, two more families are sequentially introduced intothe configuration model 304. Family “DR” is a family of drives, such as2-wheel and 4-wheel drive. Family “TRA” is a family of transmissions,such as automatic and 4-speed manual.

In the find feature window 602, the families and features are locatedand selected in operation 502. Optionalities are associated between theselected feature and selected qualifying features. Suppose the userdesires to create an additional rule in configuration model 304indicating that BAAAA is optional with the combination of featuresTRMAC, WHLAB, DR-B, and TRAAT. As discussed above, the user selectsqualifying features TRMAC, WHLAB, DR-B, and TRAAT from find featurewindow 602 and selects an optionality to relate the selected qualifyingfeatures with BAAAA. Such a rule is represented by Rule 5.

-   BAAAA O TRMAC, WHLAB, DR-B, TRAAT Rule 5.

As a side effect (to avoid rule overlap), Rule 4 is deleted and replacedby Rules 6, 7, and 8. Rule 6 indicates that BAAAA is standard withfeature TRMAC and all wheels except WHLAA and WHLAB. Rule 7 and 8respectively indicate that BAAAA is standard (S) with TRMAC, WHLAB, andall drives except DR-B and BAAAA is standard with TRMAC, WHLAB, DR-B,and all transmissions except TRAAT.

-   BAAAA S TRMAC, ˜{WHLAA, WHLAB} Rule 6.-   BAAAA S TRMAC, WHLAB, ˜{DR-B} Rule 7.-   BAAAA S TRMAC, WHLAB, DR-B, ˜{TRAAT} Rule 8.

Therefore the current set of BAAAA rules in the configuration model 304are:

-   BAAAA M TRMAC, WHLAA Rule 2.-   BAAAA S ˜{TRMAC} Rule 3.-   BAAAA O TRMAC, WHLAB, DR-B, TRAAT Rule 5.-   BAAAA S TRMAC, ˜{WHLAA, WHLAB} Rule 6.-   BAAAA S TRMAC, WHLAB, ˜{DR-B} Rule 7.-   BAAAA S TRMAC, WHLAB, DR-B, ˜{TRAAT} Rule 8.

Operation 504 queries for all rules with BAAAA on the LHS. Rules 2, 3,and 5-8 meet the query criteria. In operation 506, the related familylist consists of families TRM, WHL, DR, and TRA. In operation 508, theTRM family occurs most frequently, so TRM is placed at the root level,followed by the WHL, DR, and TRA families. Operation 510 adds Rules 5-8to configuration space 608 and deletes Rule 4. Operation 512 examines atrie that represents Rules 2, 3, and 5-8 and minimizes the configurationspace 608 by combining parent nodes having common sub-trees. Operations514-518 render the configuration space 608 into a viewable HTML documentin the manner described above so that the configuration space 608 can beviewed in operation 520.

Referring to FIG. 10, the “AC,” air conditioning, family is introducedinto the configuration model 304. In the find feature window 602, the ACfamily and features are located and selected in operation 502. Supposethe user desires to create two rules in configuration model 304. Thefirst rule indicates that BAAAA is optional with the combination ofqualifying features TRMAC, WHLAA, and AC-B. As discussed above, thequalifying features are selected from find feature window 602. Theoptionality to relate the selected qualifying features to BAAAA isselected from optionality window 606 to create a rule. Such a rule isrepresented by Rule 9.

-   BAAAA O TRMAC, WHLAA, AC-B Rule 9.

As a side effect (to avoid rule overlap), Rule 2 is deleted and replacedby Rule 10. Rule 10 indicates that BAAAA is mandatory with featuresTRMAC, WHLAA, and all features of family AC except AC-B.

-   BAAAA M TRMAC, WHLAA, ˜{AC-B} Rule 10.

Rule 11 represents the second added rule referred to above, whichindicates the BAAAA is mandatory with the combination of features TRMAD,WHLAA, and AC-B.

-   BAAAA M TRMAD, WHLAA, AC-B Rule 11.

As a side effect (to avoid rule overlap), Rule 3 is deleted and replacedby Rules 12-14. Rule 12 indicates that BAAAA is standard with alltransmissions in the TRM family except TRMAC and TRMAD. Rule 13indicates that BAAAA is standard with the combination of transmissionTRMAD and all wheel features in family WHL except wheel WHLAA. Rule 14indicates that BAAAA is standard with all combinations having featuresTRMAD and WHLAA and not having feature AC-B.

-   BAAAA S ˜{TRMAC, TRMAD} Rule 12.-   BAAAA S TRMAD, ˜{WHLAA} Rule 13.-   BAAAA S TRMAD, WHLAA, ˜{AC-B} Rule 14.

Therefore the current set of BAAAA rules in the configuration model 304are:

-   BAAAA O TRMAC, WHLAB, DR-B, TRAAT Rule 5.-   BAAAA S TRMAC, ˜{WHLAA, WHLAB} Rule 6.-   BAAAA S TRMAC, WHLAB, ˜{DR-B} Rule 7.-   BAAAA S TRMAC, WHLAB, DR-B, ˜{TRAAT} Rule 8.-   BAAAA O TRMAC, WHLAA, AC-B Rule 9.-   BAAAA M TRMAC, WHLAA, ˜{AC-B} Rule 10.-   BAAAA M TRMAD, WHLAA, AC-B Rule 11.-   BAAAA S ˜{TRMAC, TRMAD} Rule 12.-   BAAAA S TRMAD, ˜{WHLAA} Rule 13.-   BAAAA S TRMAD, WHLAA, ˜{AC-B} Rule 14.

Operation 504 queries for all rules with BAAAA on the LHS. Rules 5-14meet the query criteria. In operation 506, the related family listconsists of families TRM, WHL, AC, DR, and TRA. In operation 508, theTRM family occurs most frequently, so TRM is placed at the root level,followed by the WHL, AC, DR, and TRA families. Operation 510 adds Rules9-14 to configuration space 608 and deletes Rules 2 and 3. Operation 512examines a trie that represents Rules 5-14 and minimizes theconfiguration space 608 by combining parent nodes having commonsub-trees. Operations 514-518 render the configuration space 608 into aviewable HTML document in the manner described above so that theconfiguration space 608 can be viewed in operation 520.

Referring to FIG. 11, a trie data structure 1100, or trie, extends thetypical ordered binary decision tree data structure. The ordered binarydecision tree is a tree data structure with nodes at each tree levelconnected by edges. The levels of the tree represent a single binaryvariable and are ordered in a known manner. The nodes at each levelrepresent the value of the variable (either 1 or 0). The ordered binarydecision tree can be used to evaluate whether a particular conclusioncan be reached based on the presence of a path through the tree thatmatches certain provided input criteria (typically, one or several ofthe variables with an assigned binary value).

Whereas the ordered binary decision tree assigns a binary variable to alevel and a binary value to a node, the trie data structure assigns amulti-valued variable to a level and a binary set to each node. In oneembodiment such as an automotive configuration space context, the triehas special meaning: each level 1102 of the trie is a family, the nodes1104 of the level are sets of features within this family, each feature(i.e. member of the set X1, A1, A2, A3, B1, and B2) can assume a binaryvalue, and the trie 1100 as a whole represents the optionalities and RHSfeatures of rules having a LHS feature, F.

The trie data structure represents the value of the variable at eachnode through the values of the features in the set at that node. Thevalue of the variable at each node and through all levels of the triecommunicate the value of the trie. In one embodiment of an automotiveconfiguration space context, the value of the trie can be thought of asall possible buildable configurations that include LHS feature F for thevehicle product the trie represents. Unlike other typical automotiveconfiguration approaches, the trie represents the entire space ofpossible buildable configurations for an automotive vehicle line in amanner optimized for searching as opposed to representing configurationrules between particular features.

Assuming B level represents optionalities with B1=optional andB2=standard, trie 1100 represents the following buildable configurationsas represented by paths trie 1100:

-   -   {F, X1, A1}, {F, X1, A2}, {F, X1, A3}

These buildable configurations might be expressed by the followingconfiguration rules:

F B1 X1, A1 F B2 X1, A2 F B2 X1, A3

In one embodiment, the binary form of trie 1100 uses one bit perfeature. A known family and feature ordering of the bits, a known numberof bits per family, and a value of each bit can completely define eachtrie. For example, FIG. 12 represents trie 1100 in its binary form.Since family X has only one feature, it is represented by a single bit,with 1=present and 0=absent. Family A has 3 features, B1, B2, and B3;B1=optional, B2=standard, and B3=mandatory. Thus, branch 1202 isrepresented by the binary sequence 1100100, with the most significantbit representing the X family, the next 3 most significant bitsrepresenting the A family, and the 3 least significant bits representingthe B family. Accordingly, branch 1204 is represented by the binarysequence 1010010, and branch 1206 is represented by the binary sequence1001010. It will be evident to those of ordinary skill in the art thatother coding schemes may be used to define a trie.

A trie can be minimized when a parent node has child nodes that areroots of identical sub-tries, a sub-trie being the trie beginning froman intermediate node. The sibling nodes with identical sub-tries can becombined into a single node, and the independent paths can be combinedinto a single path. In our example, the independent nodes {A2} and {A3}and paths {A2}-{B2} and {A3}-{B2} became a consolidated node {A2, A3}1302 and a reduced path {A2, A3}-{B2} 1304 as depicted in FIG. 13.

In one embodiment the minimization operation compares corresponding bitsin each sub-branch of trie 1100's binary form beginning with siblings ofthe first level and proceeding downward through the levels until theleaf level is reached. For example, the first level in trie 1100corresponds to the A family, thus, the binary forms of the sub-branchesof each feature in the A family are compared. The A1 sub-branch is 100,the A2 sub-branch is 010, and the A3 sub-branch is 010. The A2 and A3sub-branches are identical, thus A2 and A3 are combined as depicted inFIG. 13. FIG. 14 depicts trie 1100 in its minimized form with associatedbinary values.

FIG. 15 depicts one embodiment of operation 512 to minimize therepresentation of configuration space 608 by creating a new or modifyingan existing trie and then performing minimization processes aspreviously described. For a new trie or an existing trie, operation 1502adds each rule to the trie so that the trie represents the current rulesto be represented by configuration space 608. As described above, in oneembodiment, each family occupies a distinct level in the trie andoptionalities are leaf nodes. Operations 1504-1512 minimize the trierepresentation of the rules as described above. Operation 1504initializes a count variable, X, to 1, where X represents the level ofthe trie being analyzed and “1” is the highest level (“//” representsthe beginning of a comment). In operation 1506, when X represents theleaf level, no sub-tries are available to analyze and process 500proceeds to operation 514. If X is not a leaf level, then operation 1508compares sub-trees of the children of all siblings of level X. Operation1510 consolidates all siblings whose sub-trees are identical so thatthey branch from a single root, as described above. Operation 1512increments X by 1 so that any additional, nonleaf levels can be analyzedfor minimization pursuant to operations 1508-1510.

It will be understood by those of ordinary skill in the art that otherinterfaces can be used to create rules that can be transformed intoconfiguration spaces. It will also be clear to those of ordinary skillin the art that existing configuration models can be displayed usingconfiguration spaces by performing operations 502-520 on an existingconfiguration model.

FIG. 16 is a block diagram depicting one embodiment of a networkenvironment in which a configuration space system 302 may be practiced.Network 1602 (e.g. a private wide area network (WAN) or the Internet)includes a number of networked server computer systems 1604(1)-(N) thatare accessible by client computer systems 1606(1)-(N), where N is thenumber of server computer systems connected to the network.Communication between client computer systems 1606(1)-(N) and servercomputer systems 1604(1)-(N) typically occurs over a network, such as apublic switched telephone network over asynchronous digital subscriberline (ADSL) telephone lines or high-bandwidth trunks, for examplecommunications channels providing T1 or OC3 service. Client computersystems 1606(1)-(N) typically access server computer systems 1604(1)-(N)through a service provider, e.g., an Internet service provider such asAmerica On-Line™ and the like, by executing application specificsoftware, commonly referred to as a browser, on one of client computersystems 1606(1)-(N).

Client computer systems 1606(1)-(N) and/or server computer systems1604(1)-(N) may be, for example, computer systems of any appropriatedesign, including a mainframe, a mini-computer, a personal computersystem, or a wireless, mobile computing device. These computer systemsare typically information handling systems, which are designed toprovide computing power to one or more users, either locally orremotely. Such a computer system may also include one or a plurality ofinput/output (“I/O”) devices coupled to the system processor to performspecialized functions. Mass storage devices such as hard disks, CD-ROMdrives and magneto-optical drives may also be provided, either as anintegrated or peripheral device. One such example computer system isshown in detail in FIG. 17.

Embodiments of the configuration space system 302 can be implemented ona computer system such as a general-purpose computer 1700 depicted inFIG. 17. Input user device(s) 1710, such as a keyboard and/or mouse, arecoupled to a bi-directional system bus 1718. The input user device(s)1710 are for introducing user input to the computer system andcommunicating that user input to processor 1713. The computer system ofFIG. 17 also includes a video memory 1714, main memory 1715 and massstorage 1709, all coupled to bi-directional system bus 1718 along withinput user device(s) 1710 and processor 1713. The mass storage 1709 mayinclude both fixed and removable media, such as other available massstorage technology. Bus 1718 may contain, for example, 32 address linesfor addressing video memory 1714 or main memory 1715. The system bus1718 also includes, for example, an n-bit DATA bus for transferring DATAbetween and among the components, such as CPU 1709, main memory 1715,video memory 1714 and mass storage 1709, where “n” is, for example, 32or 64. Alternatively, multiplex DATA/address lines may be used insteadof separate DATA and address lines.

I/O device(s) 1719 may provide connections to peripheral devices, suchas a printer, and may also provide a direct connection to a remoteserver computer systems via a telephone link or to the Internet via aninternet service provider (ISP). I/O device(s) 1719 may also include anetwork interface device to provide a direct connection to a remoteserver computer systems via a direct network link to the Internet via aPOP (point of presence). Such connection may be made using, for example,wireless techniques, including digital cellular telephone connection,Cellular Digital Packet Data (CDPD) connection, digital satellite dataconnection or the like. Examples of I/O devices include modems, soundand video devices, and specialized communication devices such as theaforementioned network interface.

Computer programs and data are generally stored as instructions and datain mass storage 1709 until loaded into main memory 1715 for execution.Computer programs may also be in the form of electronic signalsmodulated in accordance with the computer program and data communicationtechnology when transferred via a network. The method and functionsrelating to configuration space system 302 may be implemented in acomputer program alone or in conjunction with hardware.

The processor 1713, in one embodiment, is a 32-bit microprocessormanufactured by Motorola, such as the 680160 processor or microprocessormanufactured by Intel, such as the 801686, or Pentium processor.However, any other suitable single or multiple microprocessors ormicrocomputers may be utilized. Main memory 1715 is comprised of dynamicrandom access memory (DRAM). Video memory 1714 is a dual-ported videorandom access memory. One port of the video memory 1714 is coupled tovideo amplifier 1716. The video amplifier 1716 is used to drive thedisplay 1717. Video amplifier 1716 is well known in the art and may beimplemented by any suitable means. This circuitry converts pixel DATAstored in video memory 1714 to a raster signal suitable for use bydisplay 1717. Display 1717 is a type of monitor suitable for displayinggraphic images.

The computer system described above is for purposes of example only. Theconfiguration space system 302 may be implemented in any type ofcomputer system or programming or processing environment. It iscontemplated that the configuration space system 302 might be run on astand-alone computer system, such as the one described above. Theconfiguration space system 302 might also be run from a server computersystems system that can be accessed by a plurality of client computersystems interconnected over an intranet network. Finally, theconfiguration space system 302 may be run from a server computer systemsthat is accessible to clients over the Internet.

Many embodiments of the present invention have application to a widerange of industries including the following: computer hardware andsoftware manufacturing and sales, professional services, financialservices, automotive sales and manufacturing, telecommunications salesand manufacturing, medical and pharmaceutical sales and manufacturing,and construction industries.

Although the present invention has been described in detail, it shouldbe understood that various changes, substitutions and alterations can bemade hereto without departing from the spirit and scope of the inventionas defined by the appended claims.

1. A method of displaying configuration relationships of a productwherein families of product features are related to each other throughdependencies, the method comprising: selecting one of the productfeatures; and displaying representations of the product features of oneor more of the families that relate to the selected product feature,wherein the product features of a family that have common childdependencies are consolidated into a single representation. 2-29.(canceled)